Explanation of Change

Adds a read-only Vendors tab under Workspace settings for workspaces on the vendorMatching beta with either QBO (Credit/Debit-card export) or Sage Intacct (Credit Card Charge export) connected. The list is sourced from the same Onyx data already used by the vendor selector RHP shipped in App #91886, so this change is App-only — no backend work is required. The tab shows one column (vendor name); the GL code column for QBO is a follow-up that also needs a Java AcctNum fetch in QuickbooksOnlineImporter.java — tracked in the same Expensify #650595 as Phase 2. Intacct never has a GL code so it is fully complete under Phase 1.

The visibility gate is canReadPolicyFeature(POLICY_FEATURE.VENDORS) && hasVendorFeature(policy, isBetaEnabled(BETAS.VENDOR_MATCHING)) && isMatchingVendorListLoaded(policy). The role check reuses ROLE_PERMISSION_BUNDLES in PolicyUtils.ts, which derives the ADMIN/AUDITOR bundles from Object.values(CONST.POLICY.POLICY_FEATURE) — adding POLICY_FEATURE.VENDORS gives admins WRITE and auditors READ automatically, no server-side change required. The list-loaded clause is stricter than the inline surfaces (Default vendor row, per-expense Vendor field) because a read-only externally-synced destination with no user CTA reads as broken if it opens empty; the page still ships a belt-and-braces empty state for the edge case where the tab is reached before the list populates.

For non-active workspaces the effect that triggers openPolicyAccountingPage runs in WorkspaceInitialPage, gated on the same read-access check, and the page itself is wrapped in withPolicyConnections so direct-URL access hydrates connections before evaluating the wrapper. Offline and Onyx-hydration-race cases are handled by mirroring withPolicyConnections's isOffline and isLoadingOnyxValue guards.

Fixed Issues

$ https://github.com/Expensify/Expensify/issues/650595

PROPOSAL: N/A (internal feature, no external proposal)

Tests

Prerequisites: a workspace with the vendorMatching beta enabled and either (a) QBO connected with non-reimbursable export destination set to Credit Card or Debit Card, or (b) Sage Intacct connected with Credit Card Charge export.

Happy path

1. Wait for the initial accounting sync to complete on the test workspace.
2. Open Settings → Workspaces → the test workspace.
3. Verify a new Vendors row appears in the workspace navigation (below Categories, above Tags when both are enabled).
4. Tap the row and verify the Vendors page opens.
5. Verify the vendor list matches the imported vendor list from the connected accounting system (spot-check three names).
6. Verify each row has no radio/checkbox — the list is read-only.
7. Type into the search box and verify the list filters case-insensitively as you type.
8. Clear the search and verify the full list returns.

Visibility branches

9. Flip the workspace's non-reimbursable export type to Vendor Bill: for QBO via Workspace → Accounting → QuickBooks Online → Export → Company card expenses, for Intacct via Workspace → Accounting → Sage Intacct → Export → Non-reimbursable expenses. Return to Workspace settings and verify the Vendors row disappears.
10. Flip the export type back (QBO: Credit Card or Debit Card; Intacct: Credit Card Charge) and verify the row reappears.
11. Disable the vendorMatching beta for the test user and verify the Vendors row is hidden regardless of export type.

Role-based access (Control workspace)

12. Add an Auditor to the Control workspace. Log in as the Auditor and verify the Vendors row is visible and the list renders. POLICY.POLICY_FEATURE.VENDORS auto-picks up READ for Auditors via ROLE_PERMISSION_BUNDLES in PolicyUtils.ts.
13. Add a Card Admin to the same workspace. Log in as the Card Admin and verify the Vendors row is hidden (Card Admins can reach workspace settings via Expensify Card / Company Cards but do not have VENDORS in their permission bundle).

Edge cases

14. On a workspace that just enabled the beta but where the initial accounting sync hasn't yet completed: open Workspace settings and verify the Vendors row is hidden (the isMatchingVendorListLoaded clause of the gate). After the sync completes, the row appears.
15. On a workspace you have not previously visited (so policy.connections isn't hydrated on app start): paste /workspaces/<policyID>/vendors directly into the URL bar. Verify the page shows a loading indicator until withPolicyConnections hydrates the connections, then renders the list.

• Verify that no errors appear in the JS console

Offline tests

1. Complete steps 1–4 of the Tests section online, then disable your network connection.
2. Verify the Vendors page still opens from cached Onyx state and the vendor list renders as it did online.
3. Verify the search box continues to filter the cached list.
4. Reconnect coverage: on a different workspace you have not visited (so policy.connections isn't hydrated), keep the network disabled and open Workspace settings; verify the Vendors row is hidden. Re-enable the network and verify the row appears without requiring a manual navigation to Accounting — the effect refires on the isOffline transition.

• Verify that no errors appear in the JS console

QA Steps

Ping me & @heyjennahay to test!

Same as Tests - Note: tester must have the vendorMatching beta enabled

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English.
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function
• If new assets were added or existing ones were modified
• If the PR modifies code that runs when editing or sending messages
• If the PR modifies a generic component
• If the PR modifies a component related to any of the existing Storybook stories
• If the PR modifies a component or page that can be accessed by a direct deeplink
• If the PR modifies the UI or modifies the form input styles
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

MacOS: Chrome / Safari